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Abstract 

We  present  an  authentication  protocol  that  allows  a 
token,  such  as  a  smart  card,  to  authenticate  itself 
to  a  back-end  trusted  computer  system  through  an 
untrusted  reader.  This  protocol  relies  on  the  fact 
that  the  token  will  only  respond  to  queries  slowly, 
and  that  the  token  owner  will  not  sit  patiently  while 
the  reader  seems  not  to  be  working.  This  protocol 
can  be  used  alone,  with  “dumb”  memory  tokens  or 
with  processor-based  tokens. 


1  Introduction 

Smart  cards  have  been  used  in  many  applications 
that  require  that  the  data  be  secured  from  the  card¬ 
holder.  In  the  Modex  stored- value  smart  card  sys¬ 
tem,  for  example,  the  smart  card  stores  a  particular 
monetary  value.  An  attacker  who  can  successfully 
change  the  value  stored  in  the  card  can  essentially 
print  money.1  In  GSM  phones,  smart  cards  provide 
identity  information  used  to  prevent  cloning  and  in 
billing.  An  attacker  who  can  modify  that  informa¬ 
tion  can  charge  cellular  phone  calls  to  another  ac¬ 
count  [BGW98].  Smart  cards  used  to  protect  satel¬ 
lite  television  can  be  attacked  to  obtain  free  services 
[McC96] . 

These  cards  are  vulnerable  to  a  large  class  of  at¬ 
tacks  [And94,  Sch97,  Row97,  Sch98],  from  reverse¬ 
engineering  [AK96]  and  protocol  failures  [AN95] 
to  side-channel  attacks  [Koc96,  Koc98,  KSWH98, 
DKL+99]  and  fault  analysis  [BDL97,  BS97].  In  all  of 
these  attacks,  the  attacker  can  defeat  the  security  of 
the  card  by  breaching  its  secure  perimeter  and  learn¬ 
ing  the  confidential  information  stored  within.  With 
reverse-engineering,  the  attacker  defeats  the  tamper- 
reisistance  measures  directly;  with  side-channel  and 
fault-analysis  attacks,  the  attacker  exploits  weak¬ 
nesses  in  the  physical  security  to  learn  information 
within  the  secure  perimeter. 

1For  other  examples,  see  [CP93],  [SK97],  and  [RKM99]. 


There  is  another  class  of  applications  for  smart 
cards — applications  in  which  the  value  of  a  success¬ 
ful  attack  is  much  smaller.  These  cards  might  pro¬ 
vide  micropayment  information,  low-security  access 
control,  or  act  as  payment  vehicles  in  circumstances 
with  low  marginal  cost  of  goods  (pay  television,  pub¬ 
lic  transportation,  etc).  In  these  applications  we  are 
less  concerned  with  individual  fraud,  and  more  con¬ 
cerned  with  an  organized  attack  to  create  and  dis¬ 
tribute  fake  cards.  Someone  who  sneaks  onto  the 
subway  or  watches  a  satellite  movie  without  paying 
isn’t  going  to  affect  the  service  provider’s  bottom 
line,  but  someone  who  is  able  to  counterfeit  access 
tokens  that  allow  everyone  to  sneak  onto  the  subway 
or  watch  the  movie  could  collapse  the  entire  system. 
Hence,  the  primary  threat  is  not  from  an  isolated 
attack  against  a  single  card,  but  an  attack  that  can 
be  scaled  to  multiple  cards. 

The  threat  is  from  untrusted  card  readers  that  the 
user  may  stick  his  card  into.  In  this  paper,  we  pro¬ 
pose  a  low-tech  authentication  protocol  that  is  useful 
in  this  sort  of  situation.  Our  protocol  makes  use  of 
what  we  will  call  a  “slow  memory  device” :  a  device 
that  responds  to  queries  by  revealing  the  contents  of 
different  memory  locations,  but  one  that  necessarily 
takes  several  seconds  to  do  so. 

The  protocol  relies  on  the  fact  that  the  cardholder 
does  not  have  infinite  patience.  If  he  puts  his  smart 
card  into  a  reader  and  nothing  happens  for  several 
seconds,  he  will  likely  pull  the  card  out  and  try 
again.  If  nothing  happens  again,  he  will  find  an¬ 
other  reader.  The  slow  response  of  the  card  ensures 
that  a  fraudulent  reader  can  only  do  so  much  dam¬ 
age  before  the  cardholder  removes  his  card. 

This  protocol  makes  no  cryptographic  assumptions, 
and  is  independent  of  any  cryptography  that  may  or 
may  not  be  in  the  system.  It  can  be  implemented  by 
itself,  or  in  conjunction  with  cryptographic  controls. 

The  rest  of  the  paper  is  organized  as  follows.  In  Sec¬ 
tion  2  we  describe  the  slow  memory  device  and  its 
functionality.  In  Section  3,  we  describe  our  authen¬ 
tication  protocol.  In  Section  4  we  discuss  variants 
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and  extensions  to  this  basic  protocol,  and  in  Section 
5  we  discuss  applications. 

2  The  Slow  Memory  Device 

This  protocol  assumes  the  existence  of  a  slow  mem¬ 
ory  token.  By  this  we  mean  a  token — a  smart  card, 
a  Dallas  Semiconductor  iButton,  etc. — that  acts  as 
a  memory  device,  but  never  responds  to  a  request  in 
less  than  t  seconds  (t  =  10,  for  the  purposes  of  this 
example).  It  is  impossible  for  a  terminal  to  get  more 
information  during  that  time;  the  token’s  electronics 
are  such  that  it  simply  cannot  respond  to  requests 
faster. 

This  memory  token  has  m  memory  locations,  each  w 
bits  wide  (w  =  64  for  the  purposes  of  this  example) . 
The  token  does  not  need  a  processor,  nor  does  it 
need  to  implement  any  cryptographic  primitives  in 
order  to  execute  this  protocol. 

3  The  Basic  Protocol 

There  are  three  parties  in  this  protocol: 

•  The  Token:  The  slow  memory  device. 

•  The  Terminal:  The  untrusted  card  reader. 

•  The  Trusted  Machine:  A  trusted  computer 
connected  to,  and  possibly  remote  from,  the 
Terminal. 

Our  authentication  protocol  is  simple.  A  user  inserts 
his  Token  into  a  Terminal.  The  Terminal  now  needs 
to  prove  to  a  Trusted  Machine  that  the  Token  is 
currently  inserted  into  the  Terminal. 

The  Terminal  is  only  marginally  trusted,  and  could 
be  malicious.  In  order  to  complete  the  protocol  cor¬ 
rectly  the  Terminal  must  be  connected,  via  a  secure 
data  link,  to  a  Trusted  Device.  The  Trusted  Device 
keeps  an  exact  copy  of  the  contents  of  the  Token; 
this  is  a  shared  secret  that  the  Terminal  does  not 
know. 

Our  protocol  is  as  follows: 

(1)  The  holder  of  the  Token  inserts  it  into  the  Ter¬ 
minal. 

(2)  Terminal  reads  the  header  information  from  the 
Token. 


(3)  Terminal  sends  this  information  over  an  en¬ 
crypted  link  to  the  Trusted  Device. 

(4)  Trusted  Device  generates  a  random  challenge 
and  sends  it  back  over  the  encrypted  link  to  the 
Terminal.  This  challenge  consists  of  a  list  of  n 
memory  locations  on  the  Token. 

(5)  Terminal  reads  the  n  memory  locations  from 
the  Token,  XORs  them  all  together,  and  sends 
the  result  back  over  the  encrypted  link  to  the 
Trusted  Device. 

(6)  The  Trusted  Device  verifies  this  information;  if 
it  checks  out,  it  believes  that  the  Token  is  cur¬ 
rently  inserted  into  the  Terminal. 

Note  that  there  are  no  cryptographic  primitives  in 
the  protocol:  the  only  mathematical  operation  in¬ 
volved  is  XOR.  There  are  no  encryption  functions, 
one-way  hash  functions,  or  message  authentication 
codes  used  in  the  protocol. 

The  Token  might  have  1000  64-bit  memory  loca¬ 
tions.  Each  time  read  request  comes  in,  it  takes  ten 
seconds  to  respond,  and  without  reverse-engineering 
the  device  and  tampering  with  its  internals,  this 
can’t  be  made  any  faster.  Assuming  ten  seconds  per 
communications  exchange,  and  setting  n  =  1,  steps 
(2)  and  (3)  take  ten  seconds,  step  (4)  takes  another 
ten  seconds,  and  step  (5)  takes  another  ten  seconds. 
This  gives  us  a  total  of  30  seconds  per  transaction. 
Now,  this  can  be  extended  a  little  bit  without  the 
user  knowing.  A  malicious  Terminal  might  ignore 
the  protocol  completely,  and  simply  query  the  Token 
(repeat  step  (5)).  Maybe  the  Terminal  can  perform 
six  queries  instead  of  one,  doubling  the  transaction 
time,  before  the  Token  owner  removes  his  card. 

To  provide  adequate  security,  we  need  to  account  for 
possible  malicious  behavior  by  the  Terminal  in  how 
many  transactions  are  allowed,  keeping  the  probabil¬ 
ity  of  success  acceptably  low  even  if  most  Terminals 
are  corrupt. 

3.1  Reasonable  Values  for  n 

Suppose  the  Token  has  m  memory  locations,  that 
each  instance  of  the  protocol  requests  the  XOR  of 
n  random  locations,  and  that  n  «  in.  Assuming 
an  attacker  eavesdrops  on  each  authentication,  he 
will  learn  the  contents  of  n  memory  locations,  not 
all  of  them  different,  after  each  transaction.  The 
average  number  of  authentications  that  the  Token 
can  accomplish  before  the  attacker  has  a  better  than 


0.5  chance  of  impersonating  the  Token  (that  is,  being 
able  to  respond  correctly  to  a  random  query),  is: 

log(n)  /  (log(m)  —  log(m  —  n)) 

For  example,  for  m  =  1000  and  n  =  5,  an  attacker 
who  eavesdrops  on  322  authentications  has  a  better 
than  0.5  probability  of  being  able  to  impersonate  the 
Token  by  answering  a  random  challenge  correctly. 

This,  of  course,  is  not  the  most  effective  attack.  A 
fraudulent  Terminal  will  specifically  query  the  To¬ 
ken  to  learn  the  memory  locations  that  it  does  not 
know.  Hence,  a  malicious  Terminal  can  learn  the 
entire  contents  of  a  Token  in  m/n  queries.  So  for 
the  parameters  above,  a  malicious  terminal  that  con¬ 
ducts  100  fraudulant  transactions  will  have  a  better 
than  0.5  probability  of  being  able  to  impersonate 
the  Token.  The  Token  owner,  though,  would  have 
to  be  convinced  to  allow  the  Token  to  be  used  in  100 
ineffectual  transactions. 


4  Extensions 

4.1  A  Button  on  the  Token 

Ideally,  we’d  have  some  user-interface  mechanism  on 
the  Token,  like  a  pushbutton.  The  Token  is  willing  to 
perform  only  once  per  button-push.  Alternatively, 
the  Token  buzzes  or  lights  up  once  per  memory  query 
answered.  This  would  make  multiple  queries  much 
harder  for  the  Terminal  to  make,  since  the  Token 
owner  could  detect  that  the  protocol  was  not  pro¬ 
ceeding  as  specified. 

4.2  Reducing  Storage  Requirements 
in  the  Trusted  Device 

As  written,  the  Trusted  Device  must  store  a  com¬ 
plete  copy  of  the  Token’s  memory  location.  If  this 
is  too  much  memory,  the  Trusted  Device  could  store 
the  Token’s  ID  information  and  a  secret  key  known 
only  to  it  (and  not  the  token).  The  Token’s  meme- 
ory  locations  would  then  be  the  memory  address  en¬ 
crypted  with  this  secret  key,  and  would  have  to  be 
loaded  onto  the  Token  by  the  Trusted  Device. 

4.3  CRC  Hardware  on  the  Token 

If  the  Token  can  afford  CRC  hardware,  then  queries 
can  be  handled  using  this  alternate  protocol: 


(1)  The  holder  of  the  Token  inserts  it  into  the  Ter¬ 
minal. 

(2)  Terminal  reads  the  header  information  from  the 
Token. 

(3)  Terminal  sends  this  information  over  an  en¬ 
crypted  link  to  the  Trusted  Device. 

(4)  Trusted  Device  generates  a  random  challenge 
and  sends  it  back  over  the  encrypted  link  to  the 
Terminal.  This  challenge  consists  of  a  list  of  n 
memory  locations  on  the  Token. 

(5a)  The  Terminal  sends  the  Token  a  request  for  the 
n  memory  locations. 

(5b)  The  Token  goes  through  the  motions  (and  de¬ 
lay)  of  sending  it  out  internally,  but  only  out¬ 
puts  the  32-bit  CRC  of  the  n  requested  memory 
locations. 

(6)  The  Trusted  Device  verifies  this  information;  if 
it  checks  out,  it  believes  that  the  Token  is  cur¬ 
rently  inserted  into  the  Terminal. 

Each  memory  location  can  now  be  32  bits  long,  and 
even  one  unknown  memory  location  in  the  query 
string  prevents  an  attacker  from  succeeding  in  an 
impersonation  attack.  Note  that  this  system  works 
best  if  there  are  lots  of  Terminals  under  different 
entities’  control.  If  a  Token  only  interacts  with  one 
Terminal  every  time  it  executes  the  protocol,  then 
this  system  doesn’t  work  very  well. 

4.4  Incrementing  Values  in  the  Token 
and  Trusted  Device 

If  we’re  worried  about  an  attacker  reverse¬ 
engineering  and  making  lots  of  copies  of  the  Token, 
then  we  have  each  query  of  memory  location  cause 
that  memory  location  to  increment  by  one,  mod¬ 
ulo  232,  or  rotate  left  one  bit,  or  whatever  else  is 
cheap  enough  to  be  implemented.  Note  that  this  up¬ 
date  must  occur  on  both  the  Token  and  the  Trusted 
Device,  and  assumes  that  there  is  either  only  one 
Trusted  Device  or  that  the  different  Trusted  Devices 
can  communicate  with  each  other  securely  to  syn- 
chromize  these  updates. 

This  variant  does  not  help  against  impersonation  at¬ 
tacks.  What  it  does  do  is  to  make  continued  synchro¬ 
nization  of  those  counterfeit  Tokens  very  expensive 
and  complex.  Now,  if  any  memory  location  in  the 
challenge  string  has  been  changed,  the  duplicated 
Token  fails  to  give  the  correct  answer. 


4.5  Reducing  the  Amount  of  Trust  in 
the  Trusted  Device 

A  given  Trusted  Device  may  be  only  partially 
trusted.  Instead  of  having  it  store  a  complete  list¬ 
ing  of  the  Token’s  memory  locations,  it  can  be  given 
a  series  of  precomputed  challenges  in  order  and  the 
right  responses  to  be  expected.  (If  we  use  the  previ¬ 
ous  extension,  this  will  work  only  for  small  numbers 
of  different  Trusted  Devices.) 


5  Security  Analysis 

The  slow  memory  protocol  is  designed  to  frustrate  a 
particular  kind  of  attack.  It  is  intended  to  provide 
security  against  an  insecure  reader  trying  to  collect 
enough  information  from  a  token  to  be  able  to  im¬ 
personate  it.  It  does  not  provide  security  against 
someone  reverse-engineering  the  token  and  cloning 
it  (although  the  extension  described  in  Section  4.2 
considerably  frustrates  that  attack  in  most  circum¬ 
stances),  nor  does  it  provide  security  in  the  event 
that  the  back-end  database  (the  Trusted  Device  in 
the  protocol)  is  compromised. 

A  more  extensive  security  analysis  will  be  in  the  final 
paper. 


6  Applications 

A  complete  discussion  of  applications,  along  with 
their  security  ramifications,  will  be  in  the  final  pa¬ 
per. 

The  most  obvious  applications  are  things  like  non- 
duplicable  keys  for  locks  and  alarms,  free  passes  or 
one-day  (or  fc-day)  coins,  and  login  keys.  In  these 
applications,  we  are  less  concerned  with  a  single  per¬ 
son  hacking  the  authentication  device  than  the  same 
single  person  being  able  to  distribute  a  large  number 
of  them. 

One  of  the  most  beneficial  aspects  of  this  protocol 
is  that  it  works  well  with  cryptography,  even  though 
it  has  no  cryptography  itself.  We  can  use  a  message 
authentication  code  such  as  HMAC  [BCK96]  in  ad¬ 
dition  to  this  protocol,  and  if  the  MAC  breaks,  the 
memory  trick  still  works.  Or  course,  all  Trusted  De¬ 
vices  must  be  trusted  with  copies  of  the  memory 
maps. 


7  Conclusions 

Security  countermeasures  must  be  commensurate 
with  the  actual  threats.  In  this  paper  we  have  pre¬ 
sented  a  low-tech  security  solution  that  helps  miti¬ 
gate  a  specific  threat,  and  can  be  used  in  conjunction 
with  other  cryptographic  countermeasures. 
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